ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group93c.txt/000019_icon-group-sender _Sat Jul 17 18:30:06 1993.msg

Internet Message Format | 1994-02-02 | 4KB

Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 19:46:19 MST
Date: 17 Jul 93 18:30:06 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago
Subject: Re: Help sought tuning Icon programs
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Status: R
Errors-To: [e-mail]

[e-mail] (Norman Ramsey) writes:
>
>I have a useful Icon program of about 1400 lines, but its utility is
>greatly diminished by its lack of speed.

This is a typical problem I have as well.  There's always a big ques-
tion I have to answer, before writing an application, just how big and
slow it will be :-), and hence whether I should take the time and trou-
ble to write it in C.  If I can, I'll always try to get away with Icon
because of the dramatically reduced time it takes to produce and debug
working code.

Generally, if I'm going to use Icon, there are several things I can do
to see if obvious speed improvements can be made.  The first is to use
the compiler.  Much has been made here about the Icon compiler's experi-
mental nature, and the existence of bugs in it.  I've found, though,
that if I can get things compiled on a SPARC, they usually run correctly,
and the speed increase can be anywhere from two to a hundredfold.

Another useful trick is to run a simple profiler.  In the Icon program
library, there is a simple program called "profile" that runs under
UNIX (and could probably be made to run under any serious operating
system).  All it does is take an Icon program compiled with the trace
option on (icont -t) and perform some rough statistics on what proce-
dures are being called the most and from where.  It's meant for inter-
active use.  You can, if you like, use it with programs not compiled
with tracing on, but rather with tracing manually set (&trace := -1) at
the point in the program where you want to start gathering statistics.

A final way of profiling Icon code is to use another Icon Program Lib-
rary program called "empg."  This is essentially an expression timing
utility.  You just give it a file containing the expressions you want
to time, and it gives you an Icon file that, when run, times those ex-
pressions, and then prints a summary of how long they took to run.  This
is the sort of utility you'd run if you had a question about whether it
was significantly faster to do things in a certain way, as compared to
some other way.

One last recommendation I'd make is that you simply post questions as
they arise.  This group has a couple of real die-hards, and a lot of
bright, interested people.  Icon isn't like Pascal or C - you have to
have an innovatory or inquisitive spirit to have found out about it, &
to have acquired facility with it.  The folks who read this group are
likely to have some really good suggestions about how to clean up any
code you write.  A case in point is the sortff routine I posted a while
back.  Bob Alexander just rewrote it for me for fun (!), and returned
a version that runs about five times as fast as my initial version.  I
took his code, debugged it, and now am testing it out.  You'll be seeing
it in a couple of days.  (Thanks, Bob.)

Hope this helps, Norman!

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]          rutgers!oddjob!ellis!goer